---
image: /generated/articles-docs-troubleshooting-video-flicker.png
id: player-flicker
title: 'Avoiding flickering in <Player>'
sidebar_label: Avoiding flickers
crumb: 'Frame-perfection'
---

Consider the following markup:

```tsx twoslash title="MyComponent.tsx"
import {AbsoluteFill, Sequence, OffthreadVideo} from 'remotion';

const MyComponent: React.FC = () => {
  return (
    <AbsoluteFill>
      <Sequence from={0} durationInFrames={120}>
        <OffthreadVideo src="https://example.com/video1.mp4" />
      </Sequence>
      <Sequence from={120} durationInFrames={120}>
        <OffthreadVideo src="https://example.com/video2.mp4" />
      </Sequence>
    </AbsoluteFill>
  );
};
```

Since Remotion is only aware of the current frame, the video with the source `video2.mp4` will only start loading once it starts appearing in the scene. This can lead to an effect in the Player where some frames will be empty, since the loading of the video will usually not complete immediately.

This is a design tradeoff of Remotion, but can be fought with different levels of aggression.

## Strategies

### Option 1: Ignore

This effect is only happening in the Remotion Studio and the Remotion Player, and will not appear in the rendered video. If you are only looking for a frame-perfect rendered video, you do not need to take additional steps.

### Option 2: Pause the `<Player />` when media is buffering

<strong style={{color: 'var(--ifm-color-primary)'}}>Recommended</strong>: This will become the default behavior in Remotion 5.0

You may want to pause the `<Player>` temporarily to allow loading of the assets and resume once the assets are ready for playback.

You can do so by adding a `pauseWhenBuffering` prop to your [`<Html5Video>`](/docs/html5-video/#pausewhenbuffering), [`<OffthreadVideo>`](/docs/offthreadvideo/#pausewhenbuffering), [`<Html5Audio>`](/docs/html5-audio/#pausewhenbuffering) and [`<Img>`](/docs/img#pausewhenloading) tags. [Learn more about the buffer state.](/docs/player/buffer-state)

:::note
The `pauseWhenBuffering` prop is enabled by default for [`<Video>`](/docs/media/video) and [`<Audio>`](/docs/media/audio) from [`@remotion/media`](/docs/media).
:::

### Option 3: Premounting the video<AvailableFrom v="4.0.140"/>

<strong style={{color: 'var(--ifm-color-primary)'}}>Recommended</strong>: This is the most effective solution.

You can mount a sequence a few frames earlier than when it starts to appear.  
This will give it time to load before it is visible to the user, which can help to avoid flickering.

See [Premounting](/docs/player/premounting) for an example.

### Option 4: Preloading to avoid network request

<strong>Recommended</strong>: This helps reduce the network loading time.

You may signal to the browser to preload videos and other assets, so that when the embedded element appears in the video, it can save the network request.

See [Preloading](/docs/player/preloading) for instructions on how to achieve this.

:::note
The signal that you give to the browser may be ignored, for example if the device has data saver or battery saver mode enabled. This is specifically a concern for mobile devices.
:::

### Option 5: Prefetching as blob URL to more aggressively avoid network request

<strong>Not recommended</strong>: Memory intensive, and only useful if prefetched before the Player is mounted, and often misused.

By [prefetching](/docs/prefetch) an asset, it will be downloaded and cached into memory.  
Unlike preloading, you force the browser to download the asset, however, you can only use the loaded asset once it has fully downloaded.

Once fully downloaded, URLs in media tags will be replaced with blob URLs.  
You must ensure that URLs are not replaced inmidst playback, otherwise playback may become worse.

It only makes sense if the prefetching finished before the media element is mounted.

:::note
Even a preloaded asset or prefetched needs to be mounted in the DOM and be decoded by the browser, which can take a short amount of time.
:::

### Option 6: Prefetching as Base64 to avoid network request and local HTTP server

<strong>Not recommended</strong>: Same drawbacks as prefetching, but with an additional performance hit, especially for large assets.

In Safari prefetching as described in Option <InlineStep>5</InlineStep> is not enough, since the Blob URL will be saved to disk and a slight delay may still occur even if the asset is pre-saved.

Alternatively, the [`prefetch()`](/docs/prefetch) function allows to fetch an asset and save it in memory as Base64, which does not require the blob URL to be loaded from disk through HTTP.

## See also

- [Preloading assets](/docs/player/preloading)
- [`prefetch()`](/docs/prefetch)
- [`@remotion/preload` vs `prefetch()`](/docs/player/preloading#remotionpreload-vs-prefetch)
- [`preloadVideo()`](/docs/preload/preload-video)
- [Flickering (during rendering)](/docs/flickering)
- [Premounting](/docs/player/premounting)
